Voice over internet protocol multimedia subsystem

ABSTRACT

This disclosure describes a communication system associated with a radio access technology (RAT). The communication system includes an Internet protocol (IP) multimedia subsystem (IMS) server, and one or more processors configured to perform operations. The operations include receiving, from a user equipment device (UE) camped on the RAT, a request for IMS Packet Data Unit (PDU) establishment or IMS session initiation protocol (SIP) registration; sending to the UE a rejection message associated with the SIP registration or the IMS PDU establishment; receiving, from the UE, an IMS failure message that comprises an IMS failure cause; determining, based on the IMS failure message, whether the IMS failure cause is temporary or permanent; and responsive to determining that the IMS failure is temporary, temporarily disabling the RAT for the UE.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to Indian Patent Application No.202141036333, filed Aug. 11, 2021, the entire contents of which areincorporated herein by reference.

TECHNICAL FIELD

The present application relates to the field of wireless communications.

BACKGROUND

Wireless communication systems are rapidly growing in usage. In recentyears, wireless devices such as smart phones and tablet computers havebecome increasingly sophisticated. In addition to supporting telephonecalls, many mobile devices now provide access to the internet, email,text messaging, and navigation using the global positioning system(GPS), and are capable of operating sophisticated applications thatutilize these functionalities.

Long Term Evolution (LTE) has become the technology of choice for themajority of wireless network operators worldwide, providing mobilebroadband data and high-speed Internet access to their subscriber base.LTE defines a number of downlink (DL) physical channels, categorized astransport or control channels, to carry information blocks received frommedium access control (MAC) and higher layers. LTE also defines a numberof physical layer channels for the uplink (UL).

A proposed next telecommunications standard moving beyond the currentInternational Mobile Telecommunications-Advanced (IMT-Advanced)Standards is called 5th generation mobile networks or 5th generationwireless systems, or 5G for short (otherwise known as 5G-NR for 5G NewRadio, also simply referred to as NR). 5G-NR proposes a higher capacityfor a higher density of mobile broadband users, also supportingdevice-to-device, ultra-reliable, and massive machine communications, aswell as lower latency and lower battery consumption, than current LTEstandards. Further, the 5G-NR standard may allow for less restrictive UEscheduling as compared to current LTE standards. Consequently, effortsare being made in ongoing developments of 5G-NR to take advantage ofhigher throughputs possible at higher frequencies

SUMMARY

In the 5th generation mobile communication system (5GS) specified by3GPP, voice services are supported via an Internet Protocol (IP)multimedia subsystem (IMS). For various reasons, it is possible thatvoice over IMS may not be available or may become unavailable on a 5Gcell while the UE is camped on it. In existing configurations of 5GS,when voice over IMS becomes unavailable for a UE that is operating in asingle-registration mode, if the UE's usage setting is “voice centric”(e.g., support of voice services is essential for the user), the UEdisables its 5G capability (“N1 mode”) so that it no longer attempts tocamp on the 5G cell or register via 5G. Instead, the UE selects anotherRAT where Evolved Packet Core (EPC) is available (e.g., as specified in3GPP TS 24.301 section 4.9.2). A similar configuration is also definedfor LTE (e.g., in 3GPP TS 24.301 section 4.3.2.4). After disabling theN1 or LTE mode (“N1/LTE mode”), the UE starts a timer for re-enablingN1/LTE mode. In order to enable N1/LTE mode once the timer expires, theUE stores the identity of the public land mobile network (PLMN) in whichN1/LTE mode was disabled. Once the timer expires, the UE uses the storedidentity to re-enable N1/LTE mode.

However, existing configurations do not address various scenarios, whichare detrimental to user experience, that occur due to voice over IMSbecoming unavailable. For example, the existing configurations do notaddress scenarios where the UE unnecessarily remains connected to thelow priority RAT after disabling the high priority RAT due to voice overIMS failure. Being connected to the low priority RAT for longer thannecessary is detrimental to user experience. This disclosure describesthese scenarios and provides solutions that prevent these scenarios orresulting errors, thereby improving user experience. Note that althoughthe disclosed examples describe 5G as the high priority RAT and LTE asthe low priority RAT, the disclosed embodiments are not limited to thatconfiguration.

In accordance with aspects of the present disclosure, communicationsystem associated with a radio access technology (RAT) is disclosed. Thecommunication system includes an Internet protocol (IP) multimediasubsystem (IMS) server, and one or more processors configured to performoperations. The operations include receiving, from a user equipmentdevice (UE) camped on the RAT, a request for IMS Packet Data Unit (PDU)establishment or IMS session initiation protocol (SIP) registration;sending to the UE a rejection message associated with the SIPregistration or the IMS PDU establishment; receiving, from the UE, anIMS failure message that comprises an IMS failure cause; determining,based on the IMS failure message, whether the IMS failure cause istemporary or permanent; and responsive to determining that the IMSfailure is temporary, temporarily disabling the RAT for the UE.

In some implementations, the IMS failure message further includes an IMSretry timer.

In some implementations, the operations further include generating a RATdisable timer based on the IMS retry timer, where the communicationsystem is configured to re-enable the temporarily disabled uponexpiration of the RAT disable timer.

In some implementations, the operations further include sending the RATdisable timer to the UE.

In some implementations, the operations further include detectingexpiration of the RAT disable timer; and responsively re-enabling theRAT for the UE.

In some implementations, determining that the IMS failure is temporaryoccurs in a first instance of performing the operations, and where in asecond instance of performing the operations includes: determining thatthe IMS failure is permanent; and responsively disabling the RAT for theUE permanently.

In some implementations, permanently disabling the RAT for the UEinvolves permanently disabling the RAT until usage settings of the UEchange or the UE's power cycles.

In some implementations, the RAT is a 5th generation mobilecommunication system (5GS) that supports voice over IMS.

In accordance with aspects of the present disclosure, a user equipmentdevice (UE) is disclosed. The UE includes one or more antennas; one ormore radios configured to perform cellular communication using a radioaccess technology (RAT) that supports voice over an Internet protocol(IP) multimedia subsystem (IMS), where the UE is camped on the RAT; andone or more processors coupled to the one or more radios. The one ormore processors are configured to cause the UE to perform operationsincluding: sending, to a communications network associated with the RAT,an IMS session initiation protocol (SIP) registration message;receiving, from the communications network, a message indicative of SIPrejection; determining, based on the message indicative of the SIPrejection, that the SIP rejection is temporary; starting an IMS retrytimer, wherein the UE is configured to reattempt SIP registration uponexpiration of the IMS retry timer; and sending to the communicationsnetwork an IMS failure message that comprises at least one of an IMSfailure cause or an IMS retry timer.

In some implementations, the operations further include determining anew value for the IMS retry timer, where the new value is synchronizedwith a RAT disable timer starting.

In some implementations, determining a new value for the IMS retry timerinvolves receiving from the communications network the new value for theIMS retry timer.

In some implementations, determining a new value for the IMS retry timerinvolves calculating the new value using predetermined values providedby the communications network.

In some implementations, the operations further involve detectingexpiration of the IMS retry timer; and responsively reattempting SIPregistration with the communications network.

In some implementations, the RAT is a 5th generation mobilecommunication system (5GS).

The previously-described implementations can be performed usingcomputer-implemented methods; a non-transitory, computer-readable mediumstoring computer-readable instructions to perform thecomputer-implemented methods; a processor including circuitry to executeone or more instructions that, when executed, cause the processor toperform the computer-implemented methods; and a computer systemincluding a computer memory interoperably coupled with a hardwareprocessor configured to perform the computer-implemented methods or theinstructions stored on the non-transitory, computer-readable medium.

The details of one or more implementations of the subject matterdescribed in this disclosure are set forth in the accompanying drawingsand the description. Other features, aspects, and advantages of thesubject matter will become apparent from the description, the drawings,and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A and FIG. 1B illustrate example signaling flows for synchronizingan IMS registration failure cause with a RAT disable type, according tosome implementations of the present disclosure.

FIG. 2 illustrates an example signaling flow that synchronizes an IMSretry-timer with a RAT disable timer, according to some implementationsof the present disclosure.

FIG. 3 illustrates a signaling flow for attempting IMS registration onall available cells, according to some implementations of the presentdisclosure.

FIG. 4 illustrates a signaling flow for re-enabling a RAT after one ormore new cells with acceptable radio conditions become available due toUE motion, according to some implementations of present disclosure.

FIG. 5 illustrates a signaling flow for re-enabling a disabled RAT,according to some implementations of present disclosure.

FIG. 6 illustrates a signaling flow for a UE re-enabling a high priorityRAT when IMS registration is successful over a low priority RAT,according to some implementations of present disclosure.

FIG. 7A, FIG. 7B, FIG. 8A, FIG. 8B, and FIG. 9 each illustrate aflowchart of an example method, according to some implementations of thepresent disclosure.

FIG. 10 illustrates an example of a wireless communication system,according to some implementations of present disclosure.

FIG. 11 illustrates a diagrammatic representation of hardware resources,according to some implementations of present disclosure.

Like reference numbers and designations in the various drawings indicatelike elements.

DETAILED DESCRIPTION

In the 5th generation mobile communication system (5GS) specified by the3rd Generation Partnership Project (3GPP), voice services are providedvia an Internet Protocol (IP) Multimedia Subsystem (IMS). The IMS voiceservice (also referred to as “voice over IMS” or “voice over PS” (VoPS))can be provided to a user equipment (UE) in various ways, including: (i)a radio access technology (RAT) that uses “Voice over New Radio” (VoNR),Voice over LTE (VoLTE), or “Voice over E-UTRA connected to 5G Core”(VoLTE-5GC), (ii) a RAT that is reached via inter-RAT fallback (e.g.,via handover or release with redirection from NR to E-UTRA connected to5GC), or (iii) Evolved Packet System (EPS) fallback (e.g., via handoveror release with redirection to E-UTRA connected to EPC) as “Voice overLTE” (VoLTE). When a UE connects to a wireless communication networkthat supports voice over IMS, an IMS client on the UE triggers IMSPacket Data Unit (PDU) session establishment followed by IMSregistration with an IMS server of the wireless communication network.The IMS client uses Session Initiation Protocol (SIP) messaging toregister with the IMS server.

For various reasons, it is possible that voice over IMS may not beavailable or may become unavailable on a 5G cell while the UE is campedon it. In existing configurations of 5GS, when voice over IMS becomesunavailable for a UE that is operating in a single-registration mode, ifthe UE's usage setting is “voice centric” (e.g., support of voiceservices is essential for the user), the UE disables its 5G capability(“N1 mode”) so that it no longer attempts to camp on the 5G cell orregister via 5G. Instead, the UE selects another RAT where EvolvedPacket Core (EPC) is available (e.g., as specified in 3GPP TS 24.301section 4.9.2) or may alternatively select any other system that may beavailable to make voice call. A similar configuration is also definedfor LTE (e.g., in 3GPP TS 24.301 section 4.3.2.4). After disabling theN1 or LTE mode (“N1/LTE mode”), the UE starts a timer for re-enablingN1/LTE mode. In order to enable N1/LTE mode once the timer expires, theUE stores the identity of the public land mobile network (PLMN) in whichN1/LTE mode was disabled. Once the timer expires, the UE uses the storedidentity to re-enable N1/LTE mode.

In this disclosure, the original RAT on which the UE is camped isreferred to as a “high priority RAT,” and a “low priority RAT” refers tothe RAT that the UE selects in response to IMS voice becomingunavailable on the high priority RAT. Generally, the high priority RAToffers the UE a higher quality connection or better services than thelow priority RAT. For example, for a UE that is camped on a 5G networkand selects LTE in response to voice over IMS becoming unavailable on5G, the “high priority RAT” is 5G and the “low priority RAT” is LTE.Other examples are possible.

However, existing configurations do not address various scenarios, whichare detrimental to user experience, that occur due to voice over IMSbecoming unavailable. For example, the existing configurations do notaddress scenarios where the UE unnecessarily remains connected to thelow priority RAT after disconnecting from the high priority RAT due tovoice over IMS failure. Being connected to the low priority RAT forlonger than necessary is detrimental to user experience. This disclosuredescribes these scenarios and provides solutions that prevent thesescenarios or resulting errors, thereby improving user experience. Notethat although the disclosed examples describe 5G as the high priorityRAT and LTE as the low priority RAT, the disclosed embodiments are notlimited to that configuration.

One scenario that results in errors detrimental to user experienceoccurs when a high priority RAT is disabled for a UE due to a failureduring SIP registration. When a failure occurs in SIP registration, theUE's IMS client provides the UE's non-access stratum (NAS) module withinformation indicative of the failure, including an IMS retry-timer thatindicates when the IMS client will re-attempt SIP registration. Inresponse to receiving the information, the NAS module disables the highpriority RAT for the UE and starts a timer for re-enabling the RAT.However, despite the high priority RAT being disabled due to the SIPregistration failure, the RAT disable timer is not linked with the IMSretry-timer. This disconnect can result in one or more of the followingerrors.

A first error can occur when the IMS retry-timer is smaller than the RATdisable timer. In this scenario, even though the UE can reattempt IMSregistration after the IMS retry-timer expires, the UE cannot registerwith the high priority RAT because the RAT disable timer has notexpired. As a result, the UE is forced to remain connected to the lowpriority RAT for longer. A second error can occur when the IMSretry-timer is greater than the RAT disable timer. Here, although the UEcan register with the high priority RAT once the RAT disable timerexpires, the UE cannot perform IMS registration since the IMS-retrytimer has not expired. As a result, the high priority RAT is disabledonce again, and the UE is forced to remain connected to the low priorityRAT for longer. A third error can occur when the IMS client receives apermanent SIP rejection that prevents the UE from reattempting SIPregistration or receives an indication that IMS services are notavailable. In this scenario, after the RAT disable timer expires, the UEsuccessfully registers with the high priority RAT, but cannot performIMS registration due to the permanent SIP rejection. As a result, thehigh priority RAT is disabled once again, and the UE is forced to remainconnected to the low priority RAT for longer.

Disclosed herein are methods and systems that resolve the disconnectbetween the IMS retry-timer and the RAT disable timer. In someembodiments, the IMS failure information is synchronized with the RATdisable type. More specifically, the IMS client is configured to sharean IMS registration failure cause with the NAS module that isresponsible for disabling the high priority RAT. The NAS module uses theIMS registration failure cause to determine whether to temporarily orpermanently disable the high priority RAT. In an example, if the IMSfailure cause is permanent, the NAS module determines to permanentlydisable the high priority RAT for the UE. Conversely, if the IMS failurecause is temporary, the NAS module determines to temporarily disable thehigh priority RAT for the UE.

Synchronizing the IMS failure cause with the RAT disable type prevents,for example, errors that result from the IMS client receiving apermanent SIP rejection. In some examples, the NAS module is configuredto use the IMS registration failure cause to determine the RAT disabletype for all failure scenarios, including, but not limited to, scenarioswhere IMS registration fails or IMS PDU/Packet Data Network (PDN)establishment is rejected due to a permanent cause.

FIG. 1A and FIG. 1B illustrate example signaling flows for synchronizingan IMS registration failure cause with a RAT disable type, according tosome implementations. More specifically, FIG. 1A illustrates an examplesignaling flow 100 for synchronizing an IMS failure received in a SIPmessage with a RAT disable type. In this example, a UE is camped andregistered with a 5G network that supports Voice over Packet Switched(VoPS), as shown by block 120. The UE includes a NAS module 104.Further, the UE has established an IMS PDN with the 5G network, as shownby block 122. The 5G network includes a Mobility Management Entity (MME)106, an Access and Mobility Management Function (AMF) 108, a SessionManagement Function (SMF) 110, and IMS server 112.

As shown in FIG. 1A, an IMS client 102 of the UE sends a SIP invite 124to the IMS server 112. In response, the IMS server 112 sends a SIPreject message 126 to the IMS client 102. The SIP reject message 126specifies that the IMS server 112 understood the request, but isrefusing to fulfill it and that the request should not be repeated(i.e., a permanent SIP rejection). The IMS client 102, in response toreceiving the SIP reject message 126, sends an IMS failure message 128to the NAS module 104. The IMS failure message 128 includes a cause ofthe failure and a duration of an IMS-retry timer. In this example, thecause of the failure is “permanent,” and therefore, the IMS failuremessage 128 does not include an IMS-retry timer. The NAS module 104determines the RAT disable type based on the cause of the failure. Inthis example, given that the cause is permanent, the NAS module 104determines that the RAT disable type is also permanent. Accordingly, theNAS module 104 permanently disables the first RAT for the UE until theUE usage settings change or the UE's power cycles, as shown by block130.

FIG. 1B illustrates an example signaling flow 140 for synchronizing anIMS PDU establishment reject cause with the RAT disable type. In thisexample, the UE is camped and registered with the 5G network thatsupports Voice over Packet Switched (VoPS), as shown by block 142. Asshown in FIG. 1B, the IMS client 102 sends a PDU session establishmentrequest 144 to the SMF 110. The SMF 110 sends a PDU sessionestablishment rejection message 146 to the NAS module 104, whichsubsequently shares the rejection message with the IMS client 102. Inthis example, the PDU session establishment rejection message 146includes a cause of the rejection (e.g., cause #33: requested serviceoption not subscribed).

The IMS client 102, in response to receiving the PDU sessionestablishment rejection message 146, sends an IMS failure message 148 tothe NAS module 104. The IMS failure message 148 includes a cause of thefailure and a duration of an IMS-retry timer. In this example, the causeof the failure is “permanent,” and therefore, the IMS failure message148 does not include an IMS-retry timer. The NAS module 104 determinesthe RAT disable type based on the cause of the failure. In this example,given that the cause is permanent, the NAS module 104 determines thatthe RAT disable type is permanent. Accordingly, the NAS module 104permanently disables the first RAT for the UE until the UE usagesettings change or the UE's power cycles, as shown by block 150.

In some embodiments, if the IMS registration failure is temporary, theIMS client additionally shares the IMS retry-timer with the NAS module(e.g., in an IMS failure message). Doing so enables the NAS module touse the IMS retry-timer to determine the value of the RAT disable timer.For instance, the NAS module can determine to disable the high priorityRAT for at least the duration of the IMS retry-timer. In some examples,the NAS module provides the IMS client with a new IMS retry-timer thatis equal to the RAT disable timer so that both timers are synchronized.This ensures that the IMS client does not reattempt IMS registrationuntil the RAT disable timer expires. However, if the NAS module does notprovide the IMS client with a new IMS retry-timer, then the IMS clientis configured to determine a new IMS retry-timer value using othermechanisms, e.g., mechanisms defined in 4.5 of RFC 5626 or by usingvalues recommended by the network operator.

FIG. 2 illustrates an example signaling flow 200 that synchronizes anIMS retry-timer with a RAT disable timer, according to someimplementations. In this example, a UE is camped and registered with a5G network that supports Voice over Packet Switched (VoPS), as shown byblock 220. The UE includes a NAS module 204. Further, the UE hasestablished IMS PDN with the 5G network, as shown by block 222. The 5Gnetwork includes an MME 206, an AMF 208, an SMF 210, and an IMS server212.

As shown in FIG. 2 , an IMS client 202 of the UE sends a SIP invite 224to the IMS server 212. In response, the IMS server 210 sends a SIPmessage 226 to the IMS client 202. The SIP message 226 indicates thatthe failure in SIP registration is temporary. Accordingly, upon receiptof the SIP message 226, the IMS client 202 starts an IMS-retry timer, T1, as shown by block 228. The IMS client 202 sends an IMS failuremessage 230 to the NAS module 204. The IMS failure message 230 includesa cause of the failure and a duration of an IMS-retry timer. In thisexample, the cause of the failure is “temporary,” and the IMS-retrytimer duration is T1. The NAS module 204 determines the RAT retry timervalue based on the IMS-retry timer. In this example, the NAS module 204determines that the value of the RAT retry timer is “T1+X,” as shown byblock 232. As described previously, in some examples, the IMS client 202also determines the value of the RAT retry timer and changes the valueof the IMS-retry timer to match the value of the RAT retry timer. Morespecifically, the IMS client 202 can determine the IMS-retry timer byreceiving the RAT retry timer or by using another mechanism (e.g.,calculating “T1+X,” where “X” is an implementation specific value).

Another scenario that results in errors detrimental to user experienceoccurs when a high priority RAT is disabled due to a temporary radiofailure (e.g., RACH failure, radio link failure, etc.). In thisscenario, if a UE's connection establishment fails or the connectiongets released due to a temporary radio failure during IMS registration,the UE's IMS client attempts to register for up to a maximum number oftimes. If the registration is not successful, the IMS client determinesthat IMS registration has failed and the UE camps on a low priority RAT.Existing configurations, however, do not address scenarios where the UEcan reconnect the high priority RAT, as illustrated by the followingexample scenarios.

A first example scenario occurs when multiple cells of a high priorityRAT, other than the serving cell on which the temporary radio failureoccurs, are available. Here, existing configurations do not account forthe temporary radio failure only affecting the serving cell, which iscommon due to the bursty nature of these failures. Instead, the existingconfigurations direct the UE to camp on a low priority RAT, even thoughother cells of the high priority RAT that share the PLMN and fulfill theS-criteria are available. A second example scenario occurs when the UEmoves after the temporary radio failure occurs. Here, the existingconfigurations do not account for the UE moving to a different locationwhere other high priority RAT cells are likely available. Under theexisting configurations, even if the UE moves to different locationwhere other high priority RAT cells are available, the high priority RATremains barred and the UE remains connected to the low priority RAT. Athird example scenario occurs when the temporary radio failure lasts fora short duration. In this scenario, the high priority RAT is barred fora duration that is longer than the short duration that the temporaryradio failure is expected to persist in the serving cell.

Also disclosed herein are methods and systems that prevent errors thatcan occur when a high priority RAT is disabled for a UE due to atemporary radio failure (e.g., RACH failure, radio link failure, etc.).In some embodiments, the UE is configured to attempt IMS registration onall available cells of the high priority RAT before disabling the RAT.At any given place, it is highly likely for the UE to have access to oneor more cells that satisfy the S-criteria and that are able to provide astable connection to the UE. Accordingly, for temporary radio failures,which are generally are bursty in nature and affect only a specific cell(e.g. due to interference or fading, consistent message collision, loadfactor, SINR), the UE is configured to attempt the IMS registration onall other available cells above the S-Criteria (of the current PLMN andRAT combination) before attempting to camp on the low priority RAT. Morespecifically, after detecting a bad radio condition (e.g., less than athreshold) and/or a connection establishment failure, the UE isconfigured to temporarily bar the serving cell of the high priority RAT.Then, the UE is configured to attempt IMS registration on otheravailable cells of the current PLMN. After the UE determines that nomore cells are available in the current RAT of the registered/selectedPLMN (including EPLMNs of the registered PLMN), the UE may reselect tocells belonging to other RATs (e.g., belonging to EPLMN of theregistered PLMN). Alternatively, if a predetermined maximum number ofIMS registration attempts have been performed, the UE is configured toattempt to camp on another RAT.

FIG. 3 illustrates a signaling flow 300 for attempting IMS registrationon all available cells, according to some implementations. In theexample of FIG. 3 , a UE is camped and registered on a 5G network withVoPS supported and IMS PDU established for the UE, as shown by block320. The UE includes a NAS/AS module 304. The 5G network includes Cell1(or cell 306), Cell2 (or cell 308), Cell3 (or cell 310), and AMF 312.

An IMS client 302 of the UE sends an IMS register message 322 to the NASmodule 304. The IMS register message 322 includes an uplink (UL) datarequest. As shown by block 324, due to a temporary radio failure that isdetected by the NAS/AS module 304 when attempting to communicate withCell1, the NAS module 304 temporarily bars Cell1 and selects Cell2. Insome examples, the NAS/AS module initiates a temporary barring timerthat indicates a period of time for which the cell is temporarilybarred. After expiration of an IMS retry-timer, the IMS client 302retries IMS registration, as shown by block 326. The IMS client 302sends an IMS register message 328 to the NAS module 304. The IMSregister message 328 includes an uplink (UL) data request. As shown byblock 330, due to a temporary radio failure that is detected by theNAS/AS module 304 when attempting to communicate with Cell2, the NAS/ASmodule 304 temporarily bars Cell2 and selects Cell3.

After expiration of an IMS retry-timer, the IMS client 302 retries IMSregistration, as shown by block 332. The IMS client 302 sends an IMSregister message 334 to the NAS module 304. The IMS register message 334includes an uplink (UL) data request. As shown by block 336, due to atemporary radio failure detected by the NAS/AS module 304 whenattempting to communicate with Cell3, the NAS/AS module 304 temporarilybars Cell3. This process of re-attempting registration is continueduntil a suitable cell of the RAT is found. If no suitable cells areavailable or the IMS client has reached a maximum number of registrationattempts, the UE selects another RAT and continues registration on theother RAT, as shown by block 338.

In some embodiments, the UE is configured to camp on the high priorityRAT after cells with acceptable radio conditions (e.g., greater than apredetermined threshold) of the high priority RAT become available. Morespecifically, after the UE camps on the low priority RAT, the UE isconfigured to periodically measure the radio conditions of one or morecells of the high priority RAT.

In one example, the UE is configured to periodically measure the radioconditions of the high priority RAT after the UE changes it location. Inthis example, the UE can attempt to camp on the high priority RAT whenit detects one or more new cells on which the temporary barring timer isnot running and that have acceptable radio conditions. The UE locationchange can be detected by any localization algorithm, including, but notlimited to, algorithms that use GPS data or gyroscope data. The periodicscan can be triggered on one or more cell frequencies that are stored inthe UE (which were previously detected when camping on the high priorityRAT) and/or on an inter-RAT neighboring (IRAT) neighboring cell listbroadcast on the low priority RAT. The UE can also track its motion andmake decisions based on its motion, e.g., disabling the search timer orperforming the search at a different rate compared to stationaryconditions. Additionally, the timer duration can be controlled (e.g.,optimized) based on operating conditions. For example, the timercondition can be controlled based on whether the UE is actively beingused (e.g., the screen is ON) or whether the UE to network traffic is inthe foreground or background.

FIG. 4 illustrates a signaling flow 400 for re-enabling a RAT after oneor more new cells with acceptable radio conditions become available dueto UE motion, according to some implementations. In the example of FIG.4 , a UE is camped and registered on a 5G network with VoPS supportedand IMS PDU established for the UE, as shown by block 420. The UEincludes a NAS module 404. The 5G network includes Cell1 (or cell 406),Cell2 (or cell 408), and AMF 410.

An IMS client 402 of the UE sends an IMS register message 422 to the NASmodule 404. The IMS register message 422 includes an uplink (UL) datarequest. As shown by block 424, due a temporary radio failure, the NASmodule 404 temporarily bars Cell1. The NAS module 404 then determines ifany other acceptable cells are available on the RAT. In this example,the NAS module 404 determines that acceptable cells are not available,and therefore, a new RAT selected.

As shown by block 426, the UE detects a change in location or motion. Inresponse, the UE starts measuring neighboring N1 cells (i.e., cells ofthe high priority RAT). As shown by block 428, in response to the UEdetecting a new N1 cell, the UE enables N1 and reattempts IMSregistration. In particular, the IMS client 402 sends an IMS registermessage 430 to the NAS module 404. As shown by block 432, the connectionestablishment is successful. Then, as shown by block 434, the IMSregistration is successful.

In another example, the UE attempts to camp on the high priority RATwhen it detects that the radio conditions of the previously tried cellshave improved. Additionally and/or alternatively, the UE attempts tocamp on the high priority RAT after the temporary barring timer on thepreviously tried one or more cells has expired.

FIG. 5 illustrates a signaling flow 500 for attempting to camp on a RAT,according to some implementations. In particular, signaling flow 500attempts to camp on a RAT after radio conditions of previously attemptedcells of the RAT have improved or temporary barring of the RAT has beenremoved. In the example of FIG. 5 , a UE is camped and registered on a5G network with VoPS supported and IMS PDU established for the UE, asshown by block 520. The UE includes a NAS module 504. The 5G networkincludes Cell1 (or cell 506) and AMF 508.

An IMS client 502 of the UE sends an IMS register message 522 to the NASmodule 504. The IMS register message 522 includes an uplink (UL) datarequest. As shown by block 524, the NAS/AS module 504 temporarily barsCell1 due a temporary radio failure, and initiates a temporary barringtimer for Cell1. Furthermore, because no other suitable cells of the RATare available, the UE selects another RAT (i.e., a low priority RAT) andcontinues IMS registration. As shown by block 526, the UE determinesthat the radio conditions of cells that the UE previously attempted toconnect to have improved (e.g., Cell1) or that a temporary barring timeron the previously attempted cells has expired. In response, the UEattempts to camp on N1 and reattempts IMS registration. In particular,the IMS client 502 sends an IMS register message 528 to the NAS module504, which attempts to camp on N1. As shown by block 530, the connectionestablishment is successful. Then, as shown by block 532, the IMSregistration is successful.

As shown by these examples, the RAT disable is optimized based on thecause of IMS registration failure. For example, for causes like RACHfailures that are bursty in nature, affecting only specific cells (e.g.due to interference or fading, consistent message collision, loadfactor, low SINR), the UE attempts the IMS registration on all availablecells in same location of same RAT and PLMN combination fulfillingS-criteria. Also, whenever UE detects that the it has moved from thearea where the connection establishment issues were seen previously orthrough measurements detects that new cells are available or detect thatthe connection establishment can be reattempted, the UE reselects backto high priority RAT cells.

Yet another scenario that results in errors detrimental to userexperience occurs when the IMS registration failure is temporary.According to existing specifications, if IMS registration fails on thehigh priority RAT, the UE is still forced to select a low priority RATeven when the IMS registration failure is temporary. As a result, the UEis forced to remain on the low priority RAT even after the temporaryfailure is resolved.

Disclosed herein are methods and systems that prevent errors that canoccur when the high priority RAT is disabled due to a temporary radiofailure.

In some embodiments, when a high priority RAT is disabled due to atemporary IMS registration failure, and the UE is successfully campedand registered on a low priority RAT, the UE is configured to re-enablethe high priority RAT and reselect a high priority RAT cell. In oneexample, the UE is camped and registered on a low priority RAT thatsupports interworking with the high priority RAT. Because the lowpriority RAT supports interworking with the high priority RAT, the IMSPDN is established with support for interworking with the higherpriority RAT.

In this example, the UE is configured to search for a high priority RATcell of the same registered PLMN that supports VoPS and that is withinthe S-criteria. If such a high priority RAT cell is found, the UE isconfigured to re-enable the high priority RAT and move to the highpriority RAT cell. The move to the high priority RAT includes IMS PDNand the active IMS registration, both of which are valid across the RATsdue to the interworking support. In this way, the UE is able to resolveany IMS failure while operating on the high priority RAT, which offersbetter user experience. However, if the high priority RAT indicatesduring registration that the IMS PDN cannot be re-established on thehigh priority RAT, the UE will again disable the high priority RAT(e.g., as specified in 3GPP TS 24.501 section 4.3.2 and TS 24.301section 4.9.2).

FIG. 6 illustrates a signaling flow 600 for a UE 602 re-enabling a highpriority RAT when IMS registration is successful over a low priorityRAT, according to some implementations. As shown by block 610, the UE602 is camped and registered on a 5G network that supports VoPS. Also,IMS PDU is established for the UE 602. The UE 602 sends an IMS registermessage 612 to IMS servers 608. In this example, the registration fails,and therefore, the IMS servers 608 send a failure message 614 to the UE602. Here, the failure message 614 specifies a “SIP 500 server error.”

As shown by block 616, in response to receiving the failure message 614,the UE 602 chooses to disable N1 and camp on the next available E-UTRANcell. Then, as shown by block 618, the UE camps and registers on LTE(e.g., via eNB/4GC 606) with VoPS supported and IMS PDN established. Inthis example, interworking to 5GS is supported by the LTE network. Giventhat the failure is temporary and that the LTE network supportsinterworking with 5GS, the UE 602 sends an IMS register message 620 tothe IMS servers 608. The IMS servers 608 send an IMS message 622 to theUE 602. The IMS message 622 includes a SIP 401 or a SIP 407 response,which are challenges by the IMS servers 608 to the registration request.In response to receiving the IMS message 622, the UE 602 generates a newregistration message with authentication, as shown by block 624. The UE602 then sends an IMS register message 626 to the IMS servers 608. Here,the IMS servers 608 approves the request, and send an IMS acceptancemessage 628 (e.g., SIP 200 OK) to the UE 602. As shown by block 630, theIMS registration is successful.

While the UE 602 is camped and registered on the low priority RAT (i.e.,LTE), the UE 602 is configured to search for a high priority RAT cell ofthe same registered PLMN that supports VoPS and satisfies theS-criteria, as shown by block 632. The UE 602 finds a high priority RAT,and in response, the UE 602 re-enables the high priority RAT and movesto the high priority RAT cell, as shown by block 634. As also shown byblock 634, the UE maps supported PDN, including the IMS PDN tocorresponding 5G network PDUs. The UE 602 then sends an IMS re-registerrequest message 636 to the IMS servers 608. In response, the IMS servers608 approve the request, and send an IMS acceptance message 638 (e.g.,SIP 200 OK) to the UE 602. As shown by block 640, the IMS registrationis successful, and the UE 602 enjoys VoPS over 5G (in addition to theother features of the high priority RAT).

In another example, after the high priority RAT is disabled due to atemporary IMS registration failure, the UE camps and registers on a lowpriority RAT that supports non-3GPP access (e.g., voice over Wi-Fi[VoWifi], WLAN, Evolved Packet Data Gateway [ePDG], etc.). Inparticular, if the UE can connect to the IMS server through non-3GPPaccess and can proceed with the IMS registration on the IMS subsystemvia the non-3GPP access. In this scenario, after successful registrationon the lower priority RAT through non-3GPP access, the UE is configuredto re-enable the higher priority RAT and reselect a suitable highpriority RAT, e.g., one that meets access criteria per the UE's policy.However, if the IMS registration fails on the non-3GPP access afterre-enabling the high priority RAT, the UE is configured to disable thehigh priority RAT (e.g., as defined in 3GPP TS 24.501 section 4.3.2 andTS 24.301 section 4.9.2).

In yet another example, after a higher priority RAT is disabled due to atemporary IMS registration failure, the UE registers with a lowerpriority RAT that does not support interworking. In this example, the UEis configured to periodically re-enable high priority RAT. A successfulIMS registration indicates that the issues in P/S/I-CSCF during theprevious IMS registration failure have been resolved. If the UEexperiences any temporary failures/unresponsive IMS server during IMSPDN establishment and/or IMS registration, the UE will once againdisable the high priority RAT (e.g., as defined in 3GPP TS 24501 section4.3.2 and TS 24301 section 4.9.2). In some examples, an incremental gapis maintained between successive RAT re-enable attempts to reducesignaling overload on network.

As shown by these examples, the RAT disable is optimized based on theIMS registration failure cause. Thus, in scenarios where the UEreselects a low priority RAT due to IMS registration failure on highpriority RAT, the UE shall camp on the low priority RAT and re-attemptIMS registration. After IMS is successfully registered on the lowpriority RAT and the UE finds a suitable high priority RAT cell of sameregistered PLMN (e.g., a cell that supports VoPS and is within theS-criteria), the UE shall re-enable the high priority RAT and reselecthigh priority RAT cell. In one example, the handover also includes thealready successful IMS PDN and registration over to high priority RAT.Alternatively, the UE will initiate PDU establishment followed by newIMS registration.

FIG. 7A, FIG. 7B, FIG. 8A, FIG. 8B, and FIG. 9 illustrate flowcharts ofexample processes, according to some implementations. For clarity ofpresentation, the description that follows generally describes theprocesses in the context of the other figures in this description. As anexample, the processes can be performed by one of a UE, a base station,or a communication system shown in FIG. 10 . However, it will beunderstood that the processes may be performed, for example, by anysuitable system, environment, software, and hardware, or a combinationof systems, environments, software, and hardware, as appropriate. Insome implementations, various steps of the processes can be run inparallel, in combination, in loops, or in any order.

FIG. 7A illustrates an example process 700 for synchronizing an IMSfailure received in a SIP message with a RAT disable type. In anembodiment, the example process 700 is performed by a communicationsystem associated with a radio access technology (RAT). In an example,the communication system includes an Internet protocol (IP) multimediasubsystem (IMS) server.

At step 702, the process 700 involves receiving, from a user equipment(UE) camped on the RAT, a request for IMS Packet Data Unit (PDU)establishment or IMS session initiation protocol (SIP) registration.

At step 704, the process 700 involves sending to the UE a rejectionmessage associated with the SIP registration or the IMS PDUestablishment.

At step 706, the process 700 involves receiving, from the UE, an IMSfailure message that comprises an IMS failure cause.

At step 708, the process 700 involves determining, based on the IMSfailure message, whether the IMS failure cause is temporary orpermanent.

At step 710, the process 700 involves responsive to determining that theIMS failure is temporary, temporarily disabling the RAT for the UE.

In some implementations, the IMS failure message further includes an IMSretry timer.

In some implementations, the process 700 further involves generating aRAT disable timer based on the IMS retry timer, where the communicationsystem is configured to re-enable the temporarily disabled uponexpiration of the RAT disable timer.

In some implementations, the process 700 further involves sending theRAT disable timer to the UE.

In some implementations, the process 700 further involves detectingexpiration of the RAT disable timer, and responsively re-enabling theRAT for the UE.

In some implementations, determining that the IMS failure is temporaryoccurs in a first instance of performing the process 700. And in asecond instance of performing the process 700, the process involvesdetermining that the IMS failure is permanent, and responsivelydisabling the RAT for the UE permanently.

In some implementations, permanently disabling the RAT for the UEinvolves permanently disabling the RAT until usage settings of the UEchange or the UE's power cycles.

In some implementations, the RAT is a 5^(th) generation mobilecommunication system (5GS) that supports voice over IMS.

FIG. 7B illustrates an example process 720 for synchronizing an IMSretry-timer with a RAT disable timer. In an embodiment, the exampleprocess 720 is performed by a user equipment device (UE). In an example,the UE includes one or more antennas, and one or more radios configuredto perform cellular communication using a radio access technology (RAT)that supports voice over an Internet protocol (IP) multimedia subsystem(IMS), where the UE is camped on the RAT.

At step 722, the process 720 involves sending, to a communicationsnetwork associated with the RAT, an IMS session initiation protocol(SIP) registration message.

At step 724, the process 720 involves receiving, from the communicationsnetwork, a message indicative of SIP rejection.

At step 726, the process 720 involves determining, based on the messageindicative of the SIP rejection, that the SIP rejection is temporary.

At step 728, the process 720 involves starting an IMS retry timer, wherethe UE is configured to reattempt SIP registration upon expiration ofthe IMS retry timer.

At step 730, the process 720 involves sending to the communicationsnetwork an IMS failure message that comprises at least one of an IMSfailure cause or an IMS retry timer.

In some implementations, the process 720 further involves determining anew value for the IMS retry timer, wherein the new value is synchronizedwith a RAT disable timer starting.

In some implementations, determining a new value for the IMS retry timerinvolves receiving from the communications network the new value for theIMS retry timer.

In some implementations, determining a new value for the IMS retry timerinvolves calculating the new value using predetermined values providedby the communications network.

In some implementations, the process 720 further involves detectingexpiration of the IMS retry timer; and responsively reattempting SIPregistration with the communications network.

In some implementations, the RAT is a 5th generation mobilecommunication system (5GS).

FIG. 8A illustrates an example process 800 for enabling a RAT. In anembodiment, the example process 800 is performed by a user equipmentdevice (UE). In an example, the UE includes one or more antennas, andone or more radios configured to perform cellular communication using aplurality of radio access technologies (RATs) that support voice over anInternet protocol (IP) multimedia subsystem (IMS).

At step 802, the process 800 involves sending, to a communicationsnetwork associated with a first RAT of the plurality of RATs, a firstrequest for IMS registration, where the UE is camped on a first cell ofthe first RAT.

At step 804, the process 800 involves determining, based on a failure ofthe IMS registration, that the IMS registration failure is due to atemporary radio failure.

At step 806, the process 800 involves responsively attempting to performthe IMS registration on at least one other cell of the first RAT.

In some implementations, the UE is barred from registering with thefirst cell after receiving the IMS rejection message.

In some implementations, attempting to perform the IMS registration onat least one other cell associated with the first RAT involves:identifying a second cell associated with the first RAT, where thesecond cell shares a public land mobile network (PLMN) with the firstcell; sending a second request for IMS registration to thecommunications network via the second cell; and receiving, from thecommunications network and via the second cell, an IMS approval messageindicating that the IMS registration is successful.

In some implementations, identifying the second cell associated with thefirst RAT involves determining that the second cell satisfies at leastone predetermined radio condition.

In some implementations, attempting to perform the IMS registration onat least one other cell associated with the first RAT involves:attempting to perform the IMS registration on each of the at least oneother cell until: (i) the IMS registration is successful on one of theat least one other cell, (ii) a threshold number of attempts have beenperformed, or (iii) registration is attempted on each of the at leastone other cell.

In some implementations, the process 800 further involves determiningthat the IMS registration on the at least one other cell has failed; andresponsively determining to camp on a second cell associated with asecond RAT of the plurality of RATs.

In some implementations, the process 800 further involves detecting athreshold location change for the UE; and responsively measuring arespective radio condition of one or more new cells associated with thefirst RAT, where the UE has not previously attempted IMS registration onthe one or more new cells.

In some implementations, the process 800 further involves determiningthat the respective radio condition of a first new cell of the one ormore new cells is greater than a predetermined threshold; responsivelydetermining to camp on the first new cell; and sending a second requestfor IMS registration to the communications network via the first newcell.

In some implementations, the process 800 further involves measuring arespective radio condition of the at least one other cell of the firstRAT.

In some implementations, the process 800 further involves determiningthat the respective radio condition of a third cell of the at least oneother cell of the first RAT satisfies a predetermined condition; andresponsively determining to camp on the third cell.

In some implementations, the process 800 further involves determiningthat a timer temporarily barring the at least one other cell or thefirst cell of the first RAT has expired; and responsively determining tocamp on one of the at least one other cell or the first cell of thefirst RAT.

FIG. 8B illustrates an example process 810 for enabling a RAT. In anembodiment, the example process 810 is performed by a user equipmentdevice (UE). In an example, the UE includes one or more antennas, andone or more radios configured to perform cellular communication using aplurality of radio access technologies (RATs) that support voice over anInternet protocol (IP) multimedia subsystem (IMS).

At step 812, the process 810 involves sending, from a user equipment(UE) to a communications network associated with a first radio accesstechnology (RAT) of the plurality of RATs, a first request for Internetprotocol (IP) multimedia subsystem (IMS) registration, where the UE iscamped on a first cell of the first RAT.

At step 814, the process 810 involves determining, based on an IMSrejection failure, that the IMS registration failure is due to atemporary radio failure.

At step 816, the process 810 involves responsively attempting to performthe IMS registration on each other cell of the first RAT until the IMSregistration is successful.

FIG. 9 illustrates a process 900 for re-enabling a high priority RAT. Inan embodiment, the example process 900 is performed by a user equipmentdevice (UE). In an example, the UE includes one or more antennas, andone or more radios configured to perform cellular communication using aplurality of radio access technologies (RATs) that support voice over anInternet protocol (IP) multimedia subsystem (IMS).

At step 902, the process 900 involves sending, using a first RAT of theplurality of RATs, a first request for IMS registration to an IMSserver.

At step 904, the process 900 involves receiving, from the IMS server, anIMS rejection message indicating failure of the IMS registration.

At step 906, the process 900 involves determining, based on the IMSrejection message, that the IMS registration failure is temporary.

At step 908, the process 900 involves responsively re-attempting IMSregistration with the IMS server.

At step 910, the process 900 involves determining to camp on the firstRAT in response to receiving an IMS acceptance message from the IMSserver.

In some implementations, the UE is camped on the first RAN, andre-attempting IMS registration with the IMS server involves:disconnecting from the first RAT and camping on a second RAT of theplurality of RATs; establishing an IMS Packet Data Network (PDN) withthe second RAT; sending, via the second RAT, a second request for IMSregistration to the IMS server; and receiving, via the second RAT, theIMS acceptance message from the IMS server.

In some implementations, the second RAT supports interworking with thefirst RAT, determining to camp on the first RAT in response to receivingthe IMS acceptance message involves: identifying a second cellassociated with the first RAT that has an acceptable radio condition;disconnecting from the second RAT and camping on the second cellassociated with the first RAT; and handing over information associatedwith the IMS PDN to the second cell.

In some implementations, the acceptable radio condition has a value thatis greater than a predetermined threshold.

In some implementations, the second RAT is a non-3GPP network.

In some implementations, the process 900 further involves periodicallyattempting to camp on the first RAT and re-attempting IMS registrationwith the IMS server via the first RAT.

In some implementations, the first RAT is a 5^(th) generation mobilecommunication system (5GS).

FIG. 10 illustrates an example of a wireless communication system 1000.For purposes of convenience and without limitation, the example system100 is described in the context of Long Term Evolution (LTE) and FifthGeneration (5G) New Radio (NR) communication standards as defined by theThird Generation Partnership Project (3GPP) technical specifications.More specifically, the wireless communication system 1000 is describedin the context of a Non-Standalone (NSA) networks that incorporate bothLTE and NR, for example, E-UTRA (Evolved Universal Terrestrial RadioAccess)-NR Dual Connectivity (EN-DC) networks, and NE-DC networks.However, the wireless communication system 1000 may also be a Standalone(SA) network that incorporates only NR. Furthermore, other types ofcommunication standards are possible, including future 3GPP systems(e.g., Sixth Generation (6G)) systems, IEEE 802.16 protocols (e.g.,WMAN, WiMAX, etc.), or the like.

As shown by FIG. 10 , the system 1000 includes UE 1001 a and UE 1001 b(collectively referred to as “UEs 1001” or “UE 1001”). In this example,UEs 1001 are illustrated as smartphones (e.g., handheld touchscreenmobile computing devices connectable to one or more cellular networks),but may also comprise any mobile or non-mobile computing device, such asconsumer electronics devices, cellular phones, smartphones, featurephones, tablet computers, wearable computer devices, personal digitalassistants (PDAs), pagers, wireless handsets, desktop computers, laptopcomputers, in-vehicle infotainment (IVI), in-car entertainment (ICE)devices, an Instrument Cluster (IC), head-up display (HUD) devices,onboard diagnostic (OBD) devices, dashtop mobile equipment (DME), mobiledata terminals (MDTs), Electronic Engine Management System (EEMS),electronic/engine control units (ECUs), electronic/engine controlmodules (ECMs), embedded systems, microcontrollers, control modules,engine management systems (EMS), networked or “smart” appliances, MTCdevices, M2M, IoT devices, and/or the like.

In some embodiments, any of the UEs 1001 may be IoT UEs, which maycomprise a network access layer designed for low-power IoT applicationsutilizing short-lived UE connections. An IoT UE can utilize technologiessuch as M2M or MTC for exchanging data with an MTC server or device viaa PLMN, ProSe or D2D communication, sensor networks, or IoT networks.The M2M or MTC exchange of data may be a machine-initiated exchange ofdata. An IoT network describes interconnecting IoT UEs, which mayinclude uniquely identifiable embedded computing devices (within theInternet infrastructure), with short-lived connections. The IoT UEs mayexecute background applications (e.g., keep-alive messages, statusupdates, etc.) to facilitate the connections of the IoT network.

The UEs 1001 may be configured to connect, for example, communicativelycouple, with RAN 1010. In embodiments, the RAN 1010 may be an NG RAN ora 5G RAN, an E-UTRAN, or a legacy RAN, such as a UTRAN or GERAN. As usedherein, the term “NG RAN” or the like may refer to a RAN 1010 thatoperates in an NR or 5G system 1000, and the term “E-UTRAN” or the likemay refer to a RAN 1010 that operates in an LTE or 4G system 1000. TheUEs 1001 utilize connections (or channels) 1003 and 1004, respectively,each of which comprises a physical communications interface or layer(discussed in further detail below).

In this example, the connections 1003 and 1004 are illustrated as an airinterface to enable communicative coupling, and can be consistent withcellular communications protocols, such as a GSM protocol, a CDMAnetwork protocol, a PTT protocol, a POC protocol, a UMTS protocol, a3GPP LTE protocol, an Advanced long term evolution (LTE-A) protocol, aLTE-based access to unlicensed spectrum (LTE-U), a 5G protocol, a NRprotocol, an NR-based access to unlicensed spectrum (NR-U) protocol,and/or any of the other communications protocols discussed herein. Inembodiments, the UEs 1001 may directly exchange communication data via aProSe interface 1005. The ProSe interface 1005 may alternatively bereferred to as a SL interface 1005 and may comprise one or more logicalchannels, including but not limited to a PSCCH, a PSSCH, a PSDCH, and aPSBCH.

The UE 1001 b is shown to be configured to access an AP 1006 (alsoreferred to as “WLAN node 1006,” “WLAN 1006,” “WLAN Termination 1006,”“WT 1006” or the like) via connection 1007. The connection 1007 cancomprise a local wireless connection, such as a connection consistentwith any IEEE 802.11 protocol, wherein the AP 1006 would comprise awireless fidelity (Wi-Fi®) router. In this example, the AP 1006 is shownto be connected to the Internet without connecting to the core networkof the wireless system (described in further detail below). In variousembodiments, the UE 1001 b, RAN 1010, and AP 1006 may be configured toutilize LWA operation and/or LWIP operation. The LWA operation mayinvolve the UE 1001 b in RRC_CONNECTED being configured by a RAN node1011 a-b to utilize radio resources of LTE and WLAN. LWIP operation mayinvolve the UE 1001 b using WLAN radio resources (e.g., connection 1007)via IPsec protocol tunneling to authenticate and encrypt packets (e.g.,IP packets) sent over the connection 1007. IPsec tunneling may includeencapsulating the entirety of original IP packets and adding a newpacket header, thereby protecting the original header of the IP packets.

The RAN 1010 can include one or more AN nodes or RAN nodes 1011 a and1011 b (collectively referred to as “RAN nodes 1011” or “RAN node 1011”)that enable the connections 1003 and 1004. As used herein, the terms“access node,” “access point,” or the like may describe equipment thatprovides the radio baseband functions for data and/or voice connectivitybetween a network and one or more users. These access nodes can bereferred to as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs or TRPs,and so forth, and can comprise ground stations (e.g., terrestrial accesspoints) or satellite stations providing coverage within a geographicarea (e.g., a cell). As used herein, the term “NG RAN node” or the likemay refer to a RAN node 1011 that operates in an NR or 5G system 1000(for example, a gNB), and the term “E-UTRAN node” or the like may referto a RAN node 1011 that operates in an LTE or 4G system 1000 (e.g., aneNB). According to various embodiments, the RAN nodes 1011 may beimplemented as one or more of a dedicated physical device such as amacrocell base station, and/or a low power (LP) base station forproviding femtocells, picocells or other like cells having smallercoverage areas, smaller user capacity, or higher bandwidth compared tomacrocells.

In some embodiments, all or parts of the RAN nodes 1011 may beimplemented as one or more software entities running on server computersas part of a virtual network, which may be referred to as a CRAN and/ora virtual baseband unit pool (vBBUP). In these embodiments, the CRAN orvBBUP may implement a RAN function split, such as a PDCP split whereinRRC and PDCP layers are operated by the CRAN/vBBUP and other L2 protocolentities are operated by individual RAN nodes 1011; a MAC/PHY splitwherein RRC, PDCP, RLC, and MAC layers are operated by the CRAN/vBBUPand the PHY layer is operated by individual RAN nodes 1011; or a “lowerPHY” split wherein RRC, PDCP, RLC, MAC layers and upper portions of thePHY layer are operated by the CRAN/vBBUP and lower portions of the PHYlayer are operated by individual RAN nodes 1011. This virtualizedframework allows the freed-up processor cores of the RAN nodes 1011 toperform other virtualized applications. In some implementations, anindividual RAN node 1011 may represent individual gNB-DUs that areconnected to a gNB-CU via individual F1 interfaces (not shown by FIG. 10). In these implementations, the gNB-DUs may include one or more remoteradio heads or RFEMs, and the gNB-CU may be operated by a server that islocated in the RAN 1010 (not shown) or by a server pool in a similarmanner as the CRAN/vBBUP. Additionally or alternatively, one or more ofthe RAN nodes 1011 may be next generation eNBs (ng-eNBs), which are RANnodes that provide E-UTRA user plane and control plane protocolterminations toward the UEs 1001, and are connected to a 5GC via an NGinterface.

In V2X scenarios one or more of the RAN nodes 1011 may be or act asRSUs. The term “Road Side Unit” or “RSU” may refer to any transportationinfrastructure entity used for V2X communications. An RSU may beimplemented in or by a suitable RAN node or a stationary (or relativelystationary) UE, where an RSU implemented in or by a UE may be referredto as a “UE-type RSU,” an RSU implemented in or by an eNB may bereferred to as an “eNB-type RSU,” an RSU implemented in or by a gNB maybe referred to as a “gNB-type RSU,” and the like. In one example, an RSUis a computing device coupled with radio frequency circuitry located ona roadside that provides connectivity support to passing vehicle UEs1001 (vUEs 1001). The RSU may also include internal data storagecircuitry to store intersection map geometry, traffic statistics, media,as well as applications/software to sense and control ongoing vehicularand pedestrian traffic. The RSU may operate on the 5.9 GHz Direct ShortRange Communications (DSRC) band to provide very low latencycommunications required for high speed events, such as crash avoidance,traffic warnings, and the like. Additionally or alternatively, the RSUmay operate on the cellular V2X band to provide the aforementioned lowlatency communications, as well as other cellular communicationsservices. Additionally or alternatively, the RSU may operate as a Wi-Fihotspot (2.4 GHz band) and/or provide connectivity to one or morecellular networks to provide uplink and downlink communications. Thecomputing device(s) and some or all of the radiofrequency circuitry ofthe RSU may be packaged in a weatherproof enclosure suitable for outdoorinstallation, and may include a network interface controller to providea wired connection (e.g., Ethernet) to a traffic signal controllerand/or a backhaul network.

Any of the RAN nodes 1011 can terminate the air interface protocol andcan be the first point of contact for the UEs 1001. In some embodiments,any of the RAN nodes 1011 can fulfill various logical functions for theRAN 1010 including, but not limited to, radio network controller (RNC)functions such as radio bearer management, uplink and downlink dynamicradio resource management and data packet scheduling, and mobilitymanagement.

In embodiments, the UEs 1001 can be configured to communicate using OFDMcommunication signals with each other or with any of the RAN nodes 1011over a multicarrier communication channel in accordance with variouscommunication techniques, such as, but not limited to, an OFDMAcommunication technique (e.g., for downlink communications) or a SC-FDMAcommunication technique (e.g., for uplink and ProSe or sidelinkcommunications), although the scope of the embodiments is not limited inthis respect. The OFDM signals can comprise a plurality of orthogonalsubcarriers.

In some embodiments, a downlink resource grid can be used for downlinktransmissions from any of the RAN nodes 1011 to the UEs 1001, whileuplink transmissions can utilize similar techniques. The grid can be atime-frequency grid, called a resource grid or time-frequency resourcegrid, which is the physical resource in the downlink in each slot. Sucha time-frequency plane representation is a common practice for OFDMsystems, which makes it intuitive for radio resource allocation. Eachcolumn and each row of the resource grid corresponds to one OFDM symboland one OFDM subcarrier, respectively. The duration of the resource gridin the time domain corresponds to one slot in a radio frame. Thesmallest time-frequency unit in a resource grid is denoted as a resourceelement. Each resource grid comprises a number of resource blocks, whichdescribe the mapping of certain physical channels to resource elements.Each resource block comprises a collection of resource elements; in thefrequency domain, this may represent the smallest quantity of resourcesthat currently can be allocated. There are several different physicaldownlink channels that are conveyed using such resource blocks.

According to various embodiments, the UEs 1001 and the RAN nodes 1011communicate data (for example, transmit and receive) data over alicensed medium (also referred to as the “licensed spectrum” and/or the“licensed band”) and an unlicensed shared medium (also referred to asthe “unlicensed spectrum” and/or the “unlicensed band”). The licensedspectrum may include channels that operate in the frequency range ofapproximately 400 MHz to approximately 3.8 GHz, whereas the unlicensedspectrum may include the 5 GHz band. NR in the unlicensed spectrum maybe referred to as NR-U, and LTE in an unlicensed spectrum may bereferred to as LTE-U, licensed assisted access (LAA), or MulteFire.

To operate in the unlicensed spectrum, the UEs 1001 and the RAN nodes1011 may operate using LAA, eLAA, and/or feLAA mechanisms. In theseimplementations, the UEs 1001 and the RAN nodes 1011 may perform one ormore known medium-sensing operations and/or carrier-sensing operationsin order to determine whether one or more channels in the unlicensedspectrum is unavailable or otherwise occupied prior to transmitting inthe unlicensed spectrum. The medium/carrier sensing operations may beperformed according to a listen-before-talk (LBT) protocol.

LBT is a mechanism whereby equipment (for example, UEs 1001 RAN nodes1011, etc.) senses a medium (for example, a channel or carrierfrequency) and transmits when the medium is sensed to be idle (or when aspecific channel in the medium is sensed to be unoccupied). The mediumsensing operation may include CCA, which utilizes at least ED todetermine the presence or absence of other signals on a channel in orderto determine if a channel is occupied or clear. This LBT mechanismallows cellular/LAA networks to coexist with incumbent systems in theunlicensed spectrum and with other LAA networks. ED may include sensingRF energy across an intended transmission band for a period of time andcomparing the sensed RF energy to a predefined or configured threshold.

Typically, the incumbent systems in the 5 GHz band are WLANs based onIEEE 802.11 technologies. WLAN employs a contention-based channel accessmechanism, called CSMA/CA. Here, when a WLAN node (e.g., a mobilestation (MS) such as UE 1001, AP 1006, or the like) intends to transmit,the WLAN node may first perform CCA before transmission. Additionally, abackoff mechanism is used to avoid collisions in situations where morethan one WLAN node senses the channel as idle and transmits at the sametime. The backoff mechanism may be a counter that is drawn randomlywithin the CWS, which is increased exponentially upon the occurrence ofcollision and reset to a minimum value when the transmission succeeds.The LBT mechanism designed for LAA is somewhat similar to the CSMA/CA ofWLAN. In some implementations, the LBT procedure for DL or ULtransmission bursts including PDSCH or PUSCH transmissions,respectively, may have an LAA contention window that is variable inlength between X and Y ECCA slots, where X and Y are minimum and maximumvalues for the CWSs for LAA. In one example, the minimum CWS for an LAAtransmission may be 9 microseconds (s); however, the size of the CWS anda MCOT (for example, a transmission burst) may be based on governmentalregulatory requirements.

The LAA mechanisms are built upon CA technologies of LTE-Advancedsystems. In CA, each aggregated carrier is referred to as a CC. A CC mayhave a bandwidth of 1.4, 3, 5, 10, 15 or 20 MHz and a maximum of fiveCCs can be aggregated, and therefore, a maximum aggregated bandwidth is100 MHz. In FDD systems, the number of aggregated carriers can bedifferent for DL and UL, where the number of UL CCs is equal to or lowerthan the number of DL component carriers. In some cases, individual CCscan have a different bandwidth than other CCs. In TDD systems, thenumber of CCs as well as the bandwidths of each CC is usually the samefor DL and UL.

CA also comprises individual serving cells to provide individual CCs.The coverage of the serving cells may differ, for example, because CCson different frequency bands will experience different pathloss. Aprimary service cell or PCell may provide a PCC for both UL and DL, andmay handle RRC and NAS related activities. The other serving cells arereferred to as SCells, and each SCell may provide an individual SCC forboth UL and DL. The SCCs may be added and removed as required, whilechanging the PCC may require the UE 1001 to undergo a handover. In LAA,eLAA, and feLAA, some or all of the SCells may operate in the unlicensedspectrum (referred to as “LAA SCells”), and the LAA SCells are assistedby a PCell operating in the licensed spectrum. When a UE is configuredwith more than one LAA SCell, the UE may receive UL grants on theconfigured LAA SCells indicating different PUSCH starting positionswithin a same subframe.

The PDSCH carries user data and higher-layer signaling to the UEs 1001.The PDCCH carries information about the transport format and resourceallocations related to the PDSCH channel, among other things. It mayalso inform the UEs 1001 about the transport format, resourceallocation, and HARQ information related to the uplink shared channel.Typically, downlink scheduling (assigning control and shared channelresource blocks to the UE 1001 b within a cell) may be performed at anyof the RAN nodes 1011 based on channel quality information fed back fromany of the UEs 1001. The downlink resource assignment information may besent on the PDCCH used for (e.g., assigned to) each of the UEs 1001.

The PDCCH uses CCEs to convey the control information. Before beingmapped to resource elements, the PDCCH complex-valued symbols may firstbe organized into quadruplets, which may then be permuted using asub-block interleaver for rate matching. Each PDCCH may be transmittedusing one or more of these CCEs, where each CCE may correspond to ninesets of four physical resource elements known as REGs. Four QuadraturePhase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCHcan be transmitted using one or more CCEs, depending on the size of theDCI and the channel condition. There can be four or more different PDCCHformats defined in LTE with different numbers of CCEs (e.g., aggregationlevel, L=1, 2, 4, or 8).

Some embodiments may use concepts for resource allocation for controlchannel information that are an extension of the above-describedconcepts. For example, some embodiments may utilize an EPDCCH that usesPDSCH resources for control information transmission. The EPDCCH may betransmitted using one or more ECCEs. Similar to above, each ECCE maycorrespond to nine sets of four physical resource elements known as anEREGs. An ECCE may have other numbers of EREGs in some situations.

The RAN nodes 1011 may be configured to communicate with one another viainterface 1012. In embodiments where the system 1000 is an LTE system(e.g., when CN 1020 is an EPC), the interface 1012 may be an X2interface 1012. The X2 interface may be defined between two or more RANnodes 1011 (e.g., two or more eNBs and the like) that connect to EPC1020, and/or between two eNBs connecting to EPC 1020. In someimplementations, the X2 interface may include an X2 user plane interface(X2-U) and an X2 control plane interface (X2-C). The X2-U may provideflow control mechanisms for user data packets transferred over the X2interface, and may be used to communicate information about the deliveryof user data between eNBs. For example, the X2-U may provide specificsequence number information for user data transferred from a MeNB to anSeNB; information about successful in sequence delivery of PDCP PDUs toa UE 1001 from an SeNB for user data; information of PDCP PDUs that werenot delivered to a UE 1001; information about a current minimum desiredbuffer size at the SeNB for transmitting to the UE user data; and thelike. The X2-C may provide intra-LTE access mobility functionality,including context transfers from source to target eNBs, user planetransport control, etc.; load management functionality; as well asinter-cell interference coordination functionality.

In embodiments where the system 1000 is a 5G or NR system (e.g., when CN1020 is an 5GC), the interface 1012 may be an Xn interface 1012. The Xninterface is defined between two or more RAN nodes 1011 (e.g., two ormore gNBs and the like) that connect to 5GC 1020, between a RAN node1011 (e.g., a gNB) connecting to 5GC 1020 and an eNB, and/or between twoeNBs connecting to 5GC 1020. In some implementations, the Xn interfacemay include an Xn user plane (Xn-U) interface and an Xn control plane(Xn-C) interface. The Xn-U may provide non-guaranteed delivery of userplane PDUs and support/provide data forwarding and flow controlfunctionality. The Xn-C may provide management and error handlingfunctionality, functionality to manage the Xn-C interface; mobilitysupport for UE 1001 in a connected mode (e.g., CM-CONNECTED) includingfunctionality to manage the UE mobility for connected mode between oneor more RAN nodes 1011. The mobility support may include contexttransfer from an old (source) serving RAN node 1011 to new (target)serving RAN node 1011; and control of user plane tunnels between old(source) serving RAN node 1011 to new (target) serving RAN node 1011. Aprotocol stack of the Xn-U may include a transport network layer builton Internet Protocol (IP) transport layer, and a GTP-U layer on top of aUDP and/or IP layer(s) to carry user plane PDUs. The Xn-C protocol stackmay include an application layer signaling protocol (referred to as XnApplication Protocol (Xn-AP)) and a transport network layer that isbuilt on SCTP. The SCTP may be on top of an IP layer, and may providethe guaranteed delivery of application layer messages. In the transportIP layer, point-to-point transmission is used to deliver the signalingPDUs. In other implementations, the Xn-U protocol stack and/or the Xn-Cprotocol stack may be same or similar to the user plane and/or controlplane protocol stack(s) shown and described herein.

The RAN 1010 is shown to be communicatively coupled to a core network-inthis embodiment, core network (CN) 1020. The CN 1020 may comprise aplurality of network elements 1022, which are configured to offervarious data and telecommunications services to customers/subscribers(e.g., users of UEs 1001) who are connected to the CN 1020 via the RAN1010. The components of the CN 1020 may be implemented in one physicalnode or separate physical nodes including components to read and executeinstructions from a machine-readable or computer-readable medium (e.g.,a non-transitory machine-readable storage medium). In some embodiments,NFV may be utilized to virtualize any or all of the above-describednetwork node functions via executable instructions stored in one or morecomputer-readable storage mediums (described in further detail below). Alogical instantiation of the CN 1020 may be referred to as a networkslice, and a logical instantiation of a portion of the CN 1020 may bereferred to as a network sub-slice. NFV architectures andinfrastructures may be used to virtualize one or more network functions,alternatively performed by proprietary hardware, onto physical resourcescomprising a combination of industry-standard server hardware, storagehardware, or switches. In other words, NFV systems can be used toexecute virtual or reconfigurable implementations of one or more EPCcomponents/functions.

Generally, the application server 1030 may be an element offeringapplications that use IP bearer resources with the core network (e.g.,UMTS PS domain, LTE PS data services, etc.). The application server 1030can also be configured to support one or more communication services(e.g., VoIP sessions, PTT sessions, group communication sessions, socialnetworking services, etc.) for the UEs 1001 via the EPC 1020.

In embodiments, the CN 1020 may be a 5GC (referred to as “5GC 1020” orthe like), and the RAN 1010 may be connected with the CN 1020 via an NGinterface 1013. In embodiments, the NG interface 1013 may be split intotwo parts, an NG user plane (NG-U) interface 1014, which carries trafficdata between the RAN nodes 1011 and a UPF, and the S1 control plane(NG-C) interface 1015, which is a signaling interface between the RANnodes 1011 and AMFs.

In embodiments, the CN 1020 may be a 5G CN (referred to as “5GC 1020” orthe like), while in other embodiments, the CN 1020 may be an EPC). WhereCN 1020 is an EPC (referred to as “EPC 1020” or the like), the RAN 1010may be connected with the CN 1020 via an S1 interface 1013. Inembodiments, the S1 interface 1013 may be split into two parts, an S1user plane (S1-U) interface 1014, which carries traffic data between theRAN nodes 1011 and the S-GW, and the S1-MME interface 1015, which is asignaling interface between the RAN nodes 1011 and MMEs.

FIG. 11 is a block diagram illustrating components, according to someexample embodiments, able to read instructions from a machine-readableor computer-readable medium (e.g., a non-transitory machine-readablestorage medium) and perform any one or more of the methodologiesdiscussed herein. Specifically, FIG. 11 shows a diagrammaticrepresentation of hardware resources 1100 including one or moreprocessors (or processor cores) 1110, one or more memory/storage devices1120, and one or more communication resources 1130, each of which may becommunicatively coupled via a bus 1140. For embodiments where nodevirtualization (e.g., NFV) is utilized, a hypervisor 1102 may beexecuted to provide an execution environment for one or more networkslices/sub-slices to utilize the hardware resources 1100.

The processors 1110 may include, for example, a processor 1112 and aprocessor 1114. The processor(s) 1110 may be, for example, a centralprocessing unit (CPU), a reduced instruction set computing (RISC)processor, a complex instruction set computing (CISC) processor, agraphics processing unit (GPU), a DSP such as a baseband processor, anASIC, an FPGA, a radio-frequency integrated circuit (RFIC), anotherprocessor (including those discussed herein), or any suitablecombination thereof.

The memory/storage devices 1120 may include main memory, disk storage,or any suitable combination thereof. The memory/storage devices 1120 mayinclude, but are not limited to, any type of volatile or nonvolatilememory such as dynamic random access memory (DRAM), static random accessmemory (SRAM), erasable programmable read-only memory (EPROM),electrically erasable programmable read-only memory (EEPROM), Flashmemory, solid-state storage, etc.

The communication resources 1130 may include interconnection or networkinterface components or other suitable devices to communicate with oneor more peripheral devices 1104 or one or more databases 1106 via anetwork 1108. For example, the communication resources 1130 may includewired communication components (e.g., for coupling via USB), cellularcommunication components, NFC components, Bluetooth® (or Bluetooth® LowEnergy) components, Wi-Fi® components, and other communicationcomponents.

Instructions 1150 may comprise software, a program, an application, anapplet, an app, or other executable code for causing at least any of theprocessors 1110 to perform any one or more of the methodologiesdiscussed herein. The instructions 1150 may reside, completely orpartially, within at least one of the processors 1110 (e.g., within theprocessor's cache memory), the memory/storage devices 1120, or anysuitable combination thereof. Furthermore, any portion of theinstructions 1150 may be transferred to the hardware resources 1100 fromany combination of the peripheral devices 1104 or the databases 1106.Accordingly, the memory of processors 1110, the memory/storage devices1120, the peripheral devices 1104, and the databases 1106 are examplesof computer-readable and machine-readable media.

It is well understood that the use of personally identifiableinformation should follow privacy policies and practices that aregenerally recognized as meeting or exceeding industry or governmentalrequirements for maintaining the privacy of users. In particular,personally identifiable information data should be managed and handledso as to minimize risks of unintentional or unauthorized access or use,and the nature of authorized use should be clearly indicated to users.

We claim:
 1. A communication system associated with a radio accesstechnology (RAT), the communication system comprising: an Internetprotocol (IP) multimedia subsystem (IMS) server; and one or moreprocessors configured to perform operations comprising: receiving, froma user equipment device (UE) camped on the RAT, a request for IMS PacketData Unit (PDU) establishment or IMS session initiation protocol (SIP)registration; sending to the UE a rejection message associated with theSIP registration or the IMS PDU establishment; receiving, from the UE,an IMS failure message that comprises an IMS failure cause; determining,based on the IMS failure message, whether the IMS failure cause istemporary or permanent; and responsive to determining that the IMSfailure is temporary, temporarily disabling the RAT for the UE.
 2. Thecommunication system of claim 1, wherein the IMS failure message furthercomprises an IMS retry timer.
 3. The communication system of claim 2,the operations further comprising: generating a RAT disable timer basedon the IMS retry timer, wherein the communication system is configuredto re-enable the temporarily disabled RAT upon expiration of the RATdisable timer.
 4. The communication system of claim 3, the operationsfurther comprising: sending the RAT disable timer to the UE.
 5. Thecommunication system of claim 3, the operations further comprising:detecting expiration of the RAT disable timer; and responsivelyre-enabling the RAT for the UE.
 6. The communication system of claim 1,wherein determining that the IMS failure is temporary occurs in a firstinstance of performing the operations, and wherein in a second instanceof performing the operations: determining that the IMS failure ispermanent; and responsively disabling the RAT for the UE permanently. 7.The communication system of claim 6, wherein permanently disabling theRAT for the UE comprises permanently disabling the RAT until usagesettings of the UE change or the UE's power cycles.
 8. The communicationsystem of claim 1, wherein the RAT is a 5th generation mobilecommunication system (5GS) that supports voice over IMS.
 9. A userequipment device (UE), comprising: one or more antennas; one or moreradios configured to perform cellular communication using a radio accesstechnology (RAT) that supports voice over an Internet protocol (IP)multimedia subsystem (IMS), wherein the UE is camped on the RAT; one ormore processors coupled to the one or more radios, wherein the one ormore processors are configured to cause the UE to perform operationscomprising: sending, to a communications network associated with theRAT, an IMS session initiation protocol (SIP) registration message;receiving, from the communications network, a message indicative of SIPrejection; determining, based on the message indicative of the SIPrejection, that the SIP rejection is temporary; starting an IMS retrytimer, wherein the UE is configured to reattempt SIP registration uponexpiration of the IMS retry timer; and sending to the communicationsnetwork an IMS failure message that comprises at least one of an IMSfailure cause or an IMS retry timer.
 10. The UE of claim 9, wherein theoperations further comprise: determining a new value for the IMS retrytimer, wherein the new value is synchronized with a RAT disable timerstarting.
 11. The UE of claim 10, wherein determining a new value forthe IMS retry timer comprises: receiving from the communications networkthe new value for the IMS retry timer.
 12. The UE of claim 10, whereindetermining a new value for the IMS retry timer comprises: calculatingthe new value using predetermined values provided by the communicationsnetwork.
 13. The UE of claim 9, the operations further comprising:detecting expiration of the IMS retry timer; and responsivelyreattempting SIP registration with the communications network.
 14. TheUE of claim 9, wherein the RAT is a 5th generation mobile communicationsystem (5GS).
 15. A non-transitory computer readable memory mediumstoring program instructions executable by processing circuitry to causea user equipment device (UE) to perform operations comprising: sending,to a communications network associated with a radio access technology(RAT) on which the UE is camped, an IMS session initiation protocol(SIP) registration message; receiving, from the communications network,a message indicative of SIP rejection; determining, based on the messageindicative of the SIP rejection, that the SIP rejection is temporary;starting an IMS retry timer, wherein the UE is configured to reattemptSIP registration upon expiration of the IMS retry timer; and sending tothe communications network an IMS failure message that comprises atleast one of an IMS failure cause or an IMS retry timer.
 16. Thenon-transitory computer readable memory medium of claim 15, wherein theoperations further comprise: determining a new value for the IMS retrytimer, wherein the new value is synchronized with a RAT disable timerstarting.
 17. The non-transitory computer readable memory medium ofclaim 16, wherein determining a new value for the IMS retry timercomprises: receiving from the communications network the new value forthe IMS retry timer.
 18. The non-transitory computer readable memorymedium of claim 16, wherein determining a new value for the IMS retrytimer comprises: calculating the new value using predetermined valuesprovided by the communications network.
 19. The non-transitory computerreadable memory medium of claim 15, the operations further comprising:detecting expiration of the IMS retry timer; and responsivelyreattempting SIP registration with the communications network.
 20. Thenon-transitory computer readable memory medium of claim 15, wherein theRAT is a 5^(th) generation mobile communication system (5GS).